Skip to content

fix: recover mTLS auth after settings races#976

Merged
EhabY merged 2 commits into
mainfrom
fix/mtls-recovery-race
May 25, 2026
Merged

fix: recover mTLS auth after settings races#976
EhabY merged 2 commits into
mainfrom
fix/mtls-recovery-race

Conversation

@EhabY
Copy link
Copy Markdown
Collaborator

@EhabY EhabY commented May 22, 2026

Closes #973

A session suspended by an mTLS or coder.headerCommand failure stayed suspended even after the user fixed the setting. Two races caused it: a request could 401 from a mid-flight settings change with no way to recover, and nothing re-tried once the fix landed.

What changes

  • Suspended sessions auto-recover once auth settings become valid again, with no logout/login round-trip.
  • Settings-race 401s retry silently under the new settings instead of escalating to an interactive prompt.
  • Retried requests don't carry stale headers from a previous header-command run.
  • Verify isn't overwritten by stale work. Logout, deployment switch, or dispose during an in-flight auth verify wins; the verify quietly bails.
  • Cross-window login is robust. A window observing an invalid token from another window keeps listening for a follow-up valid write.
  • Config-change side-effects coalesce. Reload prompts, recovery, and WebSocket reconnects fire once edits settle, not on every keystroke.
  • No stale deployment in storage when logout races a deployment write.

Tests cover silent retry, retry escalation, debounce semantics, suspended-state recovery (including the racing-clearDeployment case), and the header-cleanup-vs-session-token behaviour. pnpm typecheck, pnpm lint, and pnpm test:extension clean.

@EhabY EhabY self-assigned this May 22, 2026
@EhabY EhabY force-pushed the fix/mtls-recovery-race branch 3 times, most recently from 4afb9d2 to 0e9e93b Compare May 22, 2026 20:18
@EhabY EhabY force-pushed the fix/mtls-recovery-race branch from 0e9e93b to 0487124 Compare May 22, 2026 20:22
Comment thread src/api/authInterceptor.ts Outdated
Comment thread src/api/authInterceptor.ts Outdated
Comment thread src/api/authInterceptor.ts Outdated
Comment thread src/deployment/deploymentManager.ts Outdated
Comment thread src/api/coderApi.ts Outdated
Comment thread src/login/loginCoordinator.ts
Comment thread src/configWatcher.ts Outdated
Comment thread src/configWatcher.ts Outdated
Comment thread src/configWatcher.ts Outdated
@EhabY EhabY force-pushed the fix/mtls-recovery-race branch 2 times, most recently from 8566983 to b617e20 Compare May 25, 2026 23:21
- consolidate 401 recovery paths inside recoverFromUnauthorized
- augment axios InternalAxiosRequestConfig via .d.ts so retry/cert/header flags are typed (drops every ad-hoc cast)
- rename DeploymentManager.setDeploymentIfValid to verifyAndApplyDeployment
- switch configWatcher from leading-edge throttle to true reset-style debounce
- document headerCommandKeys cleanup on the augmented type and at the deletion site
@EhabY EhabY force-pushed the fix/mtls-recovery-race branch from b617e20 to 4ca67d8 Compare May 25, 2026 23:31
@EhabY EhabY merged commit 5637fe7 into main May 25, 2026
13 checks passed
@EhabY EhabY deleted the fix/mtls-recovery-race branch May 25, 2026 23:38
EhabY added a commit that referenced this pull request May 26, 2026
A session suspended by an mTLS or coder.headerCommand failure stayed
suspended even after the user fixed the setting. Two races caused it:
a request could 401 from a mid-flight settings change with no way to
recover, and nothing re-tried once the fix landed.

- Suspended sessions auto-recover once auth settings become valid
  again, with no logout/login round-trip.
- A 401 caused by a settings change mid-flight is retried silently
  under the new settings instead of escalating to an interactive
  prompt.
- Retried requests no longer carry stale headers from a previous
  header-command run.
- Logout, deployment switch, or dispose during an in-flight auth
  verify is no longer overwritten by the verify finishing.
- Cross-window login keeps listening if the first observed token from
  another window is invalid, so a follow-up valid write still resolves
  the dialog.
- Config-change side-effects (reload prompt, recovery, reconnects)
  fire once edits settle instead of on the first event of a burst.
- Concurrent logout no longer leaves stale deployment data in storage.

Closes #973
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mTLS users signed out on remote connect when companion settings extension activates after Coder

2 participants